I think the best approach should be to control both attributes independently, from the configuration. Something like new configuration switches named UseEnumMember (defaulting to true to keep compatibility) and UseJsonStringEnumMemberName (defaulting to false for compatibility).

Then users can opt-in to use the new JsonStringEnumMemberName attribute with config.UseJsonStringEnumMemberName = true. This will require either .NET 9 or System.Text.Json 9 for the generated code, hence being opt-in.

Additionally, users can opt-out of the old EnumMember attribute (config.UseEnumMember = false) if they identified that removing it is not an issue.

Note that the tests only asserts that the produced code compiles (CSharpCompiler.AssertCompile(code)) but asserts nothing about the serialized or deserialized JSON using the generated models, see #1738 (comment).

Yes sorry, its actually a bug in the generator. The EnumValue is actually worthless and can also be removed for STJ, right? In theory yes someone could have implemented a global custom converter

After investigation, the attribute was really working because in NSwag we generate this special converter which handles this correctly. So this was a big breaking change which this PR reverts.